package uk.org.aspellclark.gedcom.model.records;

import java.util.List;

import uk.org.aspellclark.gedcom.model.ChangeDate;
import uk.org.aspellclark.gedcom.model.UserReference;
import uk.org.aspellclark.gedcom.model.structures.NoteStructure;

/**
<pre>MULTIMEDIA_RECORD:=
    n @XREF:OBJE@ OBJE                                        {1:1}
        +1 FORM &lt;MULTIMEDIA_FORMAT>                           {1:1}
        +1 TITL &lt;DESCRIPTIVE_TITLE>                           {0:1}
        +1 &lt;&lt;NOTE_STRUCTURE>>                                 {0:M}
        +1 BLOB                                               {1:1}
            +2 CONT &lt;ENCODED_MULTIMEDIA_LINE>                 {1:M}
        +1 OBJE @&lt;XREF:OBJE>@ / chain to continued object /   {0:1}
        +1 REFN &lt;USER_REFERENCE_NUMBER>                       {0:M}
            +2 TYPE &lt;USER_REFERENCE_TYPE>                     {0:1}
        +1 RIN &lt;AUTOMATED_RECORD_ID>                          {0:1}
        +1 &lt;&lt;CHANGE_DATE>>                                    {0:1}</pre>
Large whole multimedia objects embedded in a GEDCOM file would break some systems. 
For this
purpose, large multimedia files should be divided into smaller multimedia records 
by using the
subordinate OBJE tag to chain to the next <MULTIMEDIA_RECORD> fragment. This 
will allow
GEDCOM records to be maintained below the 32K limit for use in systems with 
limited resources.
 */
public class MultimediaBlobRecord extends GedcomRecord {
	public String format;
	public String title;
	public List<NoteStructure> notes;
	public String blobData;
	public String contBlobXRef;
	public List<UserReference> userReference;
	public String rin;
	public ChangeDate changeDate;
}
